Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript ✅ grid-python studio · code
✅ grid-kotlin studio · code
✅ grid-typescript studio · code
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile SummaryExtracted 15 inline schema definitions into reusable components under
This follows OpenAPI best practices by centralizing schema definitions, reducing duplication, and improving code generation compatibility. Confidence Score: 5/5
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/config/PlatformConfigUpdateRequest.yaml | Extracted inline schema for platform config updates to reusable component |
| openapi/components/schemas/customers/BulkCustomerImportJobAccepted.yaml | Extracted inline schema for bulk import job response |
| openapi/components/schemas/invitations/UmaInvitationCreateRequest.yaml | Extracted inline schema for UMA invitation creation request |
| openapi/components/schemas/sandbox/SandboxUmaReceiveRequest.yaml | Extracted inline schema for sandbox UMA receive request |
| openapi/components/schemas/tokens/ApiTokenCreateRequest.yaml | Extracted inline schema for API token creation request |
| openapi/components/schemas/transactions/ApprovePaymentRequest.yaml | Extracted inline schema for payment approval request |
| openapi/components/schemas/transfers/TransferInRequest.yaml | Extracted inline schema for transfer-in request |
| openapi/components/schemas/transfers/TransferOutRequest.yaml | Extracted inline schema for transfer-out request |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Path Files] -->|Before: Inline Schemas| B[Request/Response Definitions]
A -->|After: $ref| C[components/schemas]
C --> D[config/PlatformConfigUpdateRequest.yaml]
C --> E[customers/KycLinkResponse.yaml]
C --> F[customers/BulkCustomerImportJobAccepted.yaml]
C --> G[invitations/UmaInvitationCreateRequest.yaml]
C --> H[invitations/UmaInvitationClaimRequest.yaml]
C --> I[sandbox/SandboxSendRequest.yaml]
C --> J[sandbox/SandboxUmaReceiveRequest.yaml]
C --> K[sandbox/SandboxFundRequest.yaml]
C --> L[tokens/ApiTokenCreateRequest.yaml]
C --> M[transactions/ApprovePaymentRequest.yaml]
C --> N[transactions/RejectPaymentRequest.yaml]
C --> O[transfers/TransferInRequest.yaml]
C --> P[transfers/TransferOutRequest.yaml]
D --> Q[Build Process]
E --> Q
F --> Q
G --> Q
H --> Q
I --> Q
J --> Q
K --> Q
L --> Q
M --> Q
N --> Q
O --> Q
P --> Q
Q -->|Bundle| R[openapi.yaml]
Q -->|Bundle| S[mintlify/openapi.yaml]
Last reviewed commit: 814f4b5
…r code gen (#219) ### TL;DR Refactored OpenAPI specification by extracting inline schema definitions into reusable schema components. ### What changed? Extracted inline schema definitions from API endpoints into separate reusable schema components in the `components/schemas` section. This affects multiple endpoints including: - Platform configuration updates (`PlatformConfigUpdateRequest`) - Customer KYC links (`KycLinkResponse`) - Transfer operations (`TransferInRequest`, `TransferOutRequest`) - Payment approvals/rejections (`ApprovePaymentRequest`, `RejectPaymentRequest`) - Bulk customer imports (`BulkCustomerImportJobAccepted`) - UMA invitations (`UmaInvitationCreateRequest`, `UmaInvitationClaimRequest`) - Sandbox operations (`SandboxSendRequest`, `SandboxUmaReceiveRequest`, `SandboxFundRequest`) - API token creation (`ApiTokenCreateRequest`) Each inline schema definition was replaced with a `$ref` reference to the corresponding component schema. ### How to test? 1. Validate the OpenAPI specification using an OpenAPI validator 2. Generate API documentation to ensure all schemas render correctly 3. Test API client generation to verify schema references resolve properly 4. Verify that all endpoint request/response schemas maintain the same structure and validation rules ### Why make this change? This refactoring improves the OpenAPI specification by: - Reducing duplication of schema definitions - Making schemas reusable across multiple endpoints - Improving maintainability by centralizing schema definitions - Following OpenAPI best practices for schema organization - Making the specification more modular and easier to manage

TL;DR
Refactored OpenAPI specification by extracting inline schema definitions into reusable schema components.
What changed?
Extracted inline schema definitions from API endpoints into separate reusable schema components in the
components/schemassection. This affects multiple endpoints including:PlatformConfigUpdateRequest)KycLinkResponse)TransferInRequest,TransferOutRequest)ApprovePaymentRequest,RejectPaymentRequest)BulkCustomerImportJobAccepted)UmaInvitationCreateRequest,UmaInvitationClaimRequest)SandboxSendRequest,SandboxUmaReceiveRequest,SandboxFundRequest)ApiTokenCreateRequest)Each inline schema definition was replaced with a
$refreference to the corresponding component schema.How to test?
Why make this change?
This refactoring improves the OpenAPI specification by: